1. Field of the Invention
The present invention relates to a method of making a link directive file, and a tool for making the link directive file, and more specifically to a method of making and updating a link directive file used for a link processing when a compiler converts a source file to an execute type file for storing directive data being memory disposition instruction information of an instruction code and variable data, and to a tool used for realizing the aforesaid method.
2. Description of the Related Art
Upon developing a program for a microcomputer a programmer performs a number of works of previously making a source file with a predetermined language, and then converting with the aid of a compiler the source file to a file (execute form) of the form which is read and executed by the microcomputer. The works are performed by the programmer who assembles a microcomputer in a desired electronic device (hereinafter referred to a target system.), and the program of the execute type file is written into a ROM (Read Only Memory). The microcomputer executes the program by reading instruction codes and variable data written in the ROM.
Recently, microcomputers have wide applications and hence sizes of programs are increased. When a new program is developed, the program is divided into a plurality of blocks, and a plurality of programmers prepare a source file for each block. These blocks are finally collected (hereinafter referred to link.) into one completed program. A processing routine frequently used in such a program is defined in a library as a function and a macro, whereby a programmer can actually makes a source file. Such a library is also linked in a final stage. Several thousand types of microcomputers are known in the world, and a programmer can select an optimum microcomputer in conformity with his application.
However, it is impossible that since instruction codes executed by microcomputers are different depending upon the types of the microcomputers, a programmer memorizes instruction codes of each type of the microcomputers. Further, it is uneconomical to prepare a program developing device for microcomputers for each type of microcomputers. For this, a programmer makes a source file in a predetermined language to which the programmer is familiar, and converts the source file to an execute form file corresponding to each type of the microcomputers using a program developing device and a conversion program supplied by a microcomputer maker. The programmer deal with various microcomputers using a program developing device by setting to the program developing device software required for program development such as a compiler, an assembler, and a linker, and inherent information for each type of microcomputers such as a device file and a link directive file (hereinafter referred to LDF).
FIG. 15 is a block diagram schematically illustrating the construction of a prior art program developing device. As illustrated in the same figure, the prior art program developing device comprises an LDF making section 73, a program making/processing section 74, an LDF 53, and a device file 61. The LDF 53 includes link directive data (hereinafter referred to LDF data) being an instruction document when a link processing is executed. The LDF making section 73 comprises a text making tool 56, a display 59, and input means 62. The programmer 51 prepares the LDF data required for the link processing while referring to a manual 52a of the microcomputer and a manual 52b of a linker 54, and stores the data in the LDF53. The program making/processing section 74 comprises a compiler 57 and a linker, in which source files 55a to 55c are converted into object files 58a to 58c, which object files are integrated into one through the linker 54 to make an execute form file 60. The compiler 57, when converting the source files 55a to 55c to the object files 58a to 58c, refers to the device file 61 specific to each microcomputer to perform a conversion processing corresponding to each microcomputer. The linker 54 likewise refers to the device file 61 for a link processing. In the following, there will be exemplarily illustrated a program development procedure in which after the source file is made, it is converted to the execute form file.
As illustrated in FIG. 15, the three source files 55a to 55c are first converted to the execute form file 60. Thereupon, in the intermediate stage compiler 57 the source files 55a to 55c are converted to the object files 58a to 58c after passage through the assembly source file. FIG. 10 is an example of the source file, and FIG. 11 is an example of the assembly source file indicating contents in the object file, obtained by compiling the source file. The assembly source file is described in a mnemonic language corresponding to the type of each microcomputer, and is a program before it is converted to the object file. The assembly source file is a program for which conversion and addresses to which the operation jumps are undefined, and in which those addresses are represented with use of labels (L4, L5) and symbols (A5[sp], [lp]). The program 51 can be executed in this status using a target system, and be debugged for each object file 58a to 58c. 
Then, the programmer 51 performs a link processing for integrating the three object files 58a to 58c into one file using a linker 54. The link processing is performed with use of the linker 54. The linker 54 links the object files 58a to 58c to make the execute form file 60 with reference to information from the LDF 53 and the device file 61.
In general, microcomputers use different types of useable instruction codes depending upon the types of themselves, and use different registers included in the microcomputers and different address spaces. ROMs (Read Only Memory)and RAMs(Random Access Memory) included in a microcomputer itself are different in their sizes depending upon the type thereof, and arrangement on the address is previously defined. Microcomputers of a certain type contain internally a RAM that operates at a high speed and contain externally a large capacity RAM that operates at a low speed. These RAMs are arranged in different address spaces. The programmer 51 develops a program to obtain maximum performance, taking performances and functions of these microcomputers into consideration. For example, the programmer 51 improves a processing speed of a program by instructing that variable data having high reference frequency are stored in the high speed RAM.
In contrast, microcomputer makers describe device information peculiar to each type of microcomputers in a manual 52a of the microcomputers, a manual 52b of the linker, and the device file 61, and provide such device information to the programmer 51. In the device file 61 there are recorded information defining the number and names of registers, the number of terminals of an input/output port, and so on. The programmer 51 prepares the LDF 53 in conformity with the construction of a microcomputer upon developing a program referring to such information. Herein, the LDF 53 means a file in which there is described an instruction to allocate various instruction codes and variable data (hereinafter referred to a section) included in the object files 58a to 58c to predetermined addresses in a memory space. For achieving the link processing as above the LED 53 is necessary.
When the object files 58a to 58c are converted to the execute form file 60, there are an instruction part(instruction code) and a variable data part (variable data) in the object files 58a to 58c. Conventionally, in the linker 54, its instruction code and variable data are disposed in a predetermined area of a memory (ROM and RAM) in conformity with ROM and RAM disposition information (hereinafter referred to memory disposition information ) of a microcomputer and the default LDF 53 or in conformity with the LDF 53 made anew. However, it is necessary to instruct such disposition in detail with use of an instruction document called LDF 53 in order to satisfactorily exhibit performance of amicrocomputer. Namely, the LDF 53 designates in detail addresses such that instruction codes and variable data are disposed at optimum positions in a memory.
Since to each microcomputer an address area in a memory is previously allocated, if there is no LDF 53, it becomes impossible to dispose instruction codes and variable data suitable for memory disposition for each microcomputer, and results in a difficulty that program development matched to a microcomputer is difficult.
Since the capacity of a memory included in a microcomputer is very smaller than that of a memory in a computer such as a personal computer, and the capacity of an included memory has a limit, it is very important to dispose instruction codes and variable data in conformity with memory disposition of a microcomputer as described above.
LDF 53 is prepared following a format that is previously determined. To the format information about memory disposition in a microcomputer is provided by the programmer 51. The linker 54 performs a link work such that instruction codes and variable data of the object files 58a to 58c can be disposed in a memory of a microcomputer. For example, it is performed as work that from what address to what address in a memory instruction codes are disposed, and that from what address to what address variable data is disposed. Further, the programmer 51 instructs variable data having high application frequency to be disposed in the high speed RAM, and variable data which is not required to be read at a very high speed to be disposed in an external low speed RAM.
FIG. 10 is an example of a source file list described in a C language. In the same figure, lines L1 to L3 define global variables a=1, b, c=0, and lines L4 to L8 define a function main ( ). Line L6 defines a local variable d, and line L7 represents execution of addition d=b+c+10. FIG. 11 is an example of a list of an assembly source file indicating contents in the object file, described in a mnemonic language which is obtained by compiling the source file illustrated in FIG. 10. In the same figure, lines L01 to L05 are a description area concerning a section xe2x80x9c. sdataxe2x80x9d, which section is read and written at a high speed with an instruction where the size of an instruction code is short, and to which section a variable having a predetermined length (e.g., variable c) belongs. Lines L06 to L07 are a description area concerning a section xe2x80x9c. sbssxe2x80x9d, which section is read and written at a high speed with an instruction where the size of an instruction code is short, but to which section a variable (e.g., a variable b) belongs, the value of which variable is undefined upon compiling and to which variable a predetermined value can be set.
Lines L08 to L12 are a description area concerning a section xe2x80x9c. constxe2x80x9d, which section can be only read and to which section a variable (e.g., a variable a) belongs. The sizes of sections xe2x80x9c. sdataxe2x80x9d, xe2x80x9c. sbssxe2x80x9d, xe2x80x9c. constxe2x80x9d are described after variable names on lines L03, L07, L10, which sizes are 4 bytes in the present example, respectively. The size corresponds to the size of each section when the execute form file is made. Lines L13 to L31 are a description area concerning a section xe2x80x9c. textxe2x80x9d, which section can be only read, and to which section a function main ( ) having an execute form code belongs. Since in the stage of the assembly resource file, an address to jump is undefined, and the accurate size of the section xe2x80x9c. textxe2x80x9d is unknown, which size is not indicated in the list. The programmer 51 can be informed of the size by executing compiling or linking. The programmer 51 can thus obtain section information of the object files 58a to 58c by converting the source files 55a to 55c to the object files 58a to 58c with use of the compiler 57.
The section is a basic unit constituting the object file 58 and corresponds to the assembly source file in FIG. 11. The object file 58a is divided into sections such as xe2x80x9c. sdataxe2x80x9d, xe2x80x9c. sbss/xe2x80x9d, xe2x80x9c. constxe2x80x9d, xe2x80x9c. textxe2x80x9d. The object files 58b, 58c have also sections illustrated in FIG. 17. Arrangements of the object file 58 and the execute form file 60 depend upon programmers, and FIG. 17 is an example of such arrangements. The linker 54 makes segments 28a to 28f by linking sections of the same type and the same attribute in the object files 58a to 58c. 
For the section attribute there are A attribute being a section occupying the memory, W attribute being a writable section, X attribute being an executable section, and G attribute being a segment which can be referred to by a global pointer, and each section in the object file 58 has one of these attributes or combined attribute where these attributes are combined.
For the section types there are PROGBITS which has an actual value in the object file 58, and NOBITS which does not have any actual value in the same.
For the kinds of the sections there are NOBITS type A,W attribute section xe2x80x9c. bssxe2x80x9d, PROGBITS type A attribute section xe2x80x9c. constxe2x80x9d, PROGBITS type A, W attribute section xe2x80x9c. dataxe2x80x9d, PROGBITS type A, X attribute section xe2x80x9c. textxe2x80x9d, and so on. For sections which have short code size instructions and to which are accessible at a high speed there are xe2x80x9c. sbssxe2x80x9d, xe2x80x9c. sconstxe2x80x9d, xe2x80x9c. sdataxe2x80x9d and so on.
The segment means a lump of sections having the same attribute and type, which is a basic unit when a program is loaded in a memory. Segment names, attributes, and addresses to be loaded, and the like can be designated by the LDF 53. The linker 54 makes as described above the segments 28a to 28c by combining several sections constituting the object files 58a to 58c. 
FIG. 12 is a view exemplarily illustrating description contents in the LDF 53. Lines LD01 to LD03 are description concerning the segment SCONST 28a, which instructs the segment SCONST 28a to link the section xe2x80x9c. sconstxe2x80x9d. Since an address to be linked is not designated, the LDF 53 disposes the section xe2x80x9c. sconstxe2x80x9d to a start address (0x000000).
Lines LD04 to LD06 are description concerning the segment TEXT 28b, which instructs the section xe2x80x9c. sconstxe2x80x9d belonging to the segment TEXT 28b to be linked, succeeding to the segment SCONST 28a. Lines LD07 to LD12 are description concerning the segment DATA 28c, which instructs sections xe2x80x9cdataxe2x80x9d, xe2x80x9c. sdataxe2x80x9d, xe2x80x9c. sbssxe2x80x9d, and xe2x80x9c. bssxe2x80x9d belonging to the segment DATA 28c from an address (0x100000) to be linked in this order.
Lines LD13 to LD15 are description concerning the segment CONST 28d, which instructs a section xe2x80x9c. constxe2x80x9d belonging to the segment CONST 28d to be linked, succeeding to the segment DATA 28c. Lines LD16 to LD19 are description concerning to a segment SEDATA 28e, which instructs sections xe2x80x9c. sedataxe2x80x9d and xe2x80x9c. sebssxe2x80x9d belonging to the segment SEDATA 28e to be linked in this order from an address (0xff6000). Lines LD20 TO LD25 are description concerning segment SIDATA 28f, which instructs sections xe2x80x9c. tidata.bytexe2x80x9d, xe2x80x9c. tidata.wordxe2x80x9d, xe2x80x9c. tidataxe2x80x9d, xe2x80x9c. sidataxe2x80x9d belonging to the segment SIDATA 28f to be linked in this order from an address (0xffe000). Lines LD26 to LD28 are description concerning a text pointer symbol tp_TEXT, a global pointer symbol gp_DATA, and an element pointer symbol ep_DATA.
The text pointer symbol tp_TEXT designates a head address of the segment TEXT, which is used as a base address upon accessing an instruction code in the segment TEXT, in which the text pointer symbol tp_TEXT is taken as a reference to access any instruction code and variable data using an offset address from the reference. This is because the instruction code and variable data are compiled not to depend upon their position to be disposed.
Hereby, even if a position of an execute file to be disposed is altered, a program can be executed only by altering the address of the text pointer symbol tp_TEXT. If the text pointer symbol tp_TEXT is not provided, the linker 54 must again calculate an address to be branched in the segment TEXT every time the size of the segment 10 SCONST linked before the segment TEXT is different. The global pointer symbol gp_DATA is the same as the text pointer symbol tp_TEXT, which pointer is used as a reference upon accessing to variable data.
More specifically, an address at which variable data is existent can be indicated with an offset address from the global pointer symbol gp_DATA. Since the sections xe2x80x9c. sbssxe2x80x9d and xe2x80x9c. sdataxe2x80x9d can be represented by a 1 byte offset address, an instruction code is shortened for high speed access. Against this, since the sections xe2x80x9c. bssxe2x80x9d and xe2x80x9c. dataxe2x80x9d can be represented by a 2 byte offset address, the instruction code is more lengthened than xe2x80x9c. sbssxe2x80x9d and xe2x80x9c.sdataxe2x80x9d correspondingly increasing access time. There is a range which is accessible by an instruction which can process at a high speed variable data in the high speed internal RAM, and the element pointer symbol ep_DATA indicates a reference to access the range.
FIG. 17 is a view illustrating a concept of the link processing. In the same figure, the left side indicates statuses of the object files 58a to 58c before subject to the link processing, and each object file 58a to 58c has a plurality of sections xe2x80x9c. textxe2x80x9d, xe2x80x9c. dataxe2x80x9d, and the like. The right side indicates the statuses of segments 28a to 28f after subject to the link processing, and the sections are linked on the basis of an instruction of the LDF 53. Arrows in the same figure indicate a positional relationship among the sections before and after the link processing.
It is noted that the arrangement of the sections of the object files 58a to 58c is different depending upon contents of the source files 55a to 55c to be developed. The segments 28a to 28f are herein constructed with the segments SCONST 28a, TEXT 28b, DATA 28c, CONST 28d, SEDATA 28e, and SIDATA 28f, although the construction is different depending upon a memory space of a microcomputer and disposition in the memory space.
The segments SCONST 28a and TEXT 28b are disposed in an internal ROM 25 (FIG. 2) described later, and the segments DATA 28c, CONST 28d, SEDATA 28e are disposed in the external RAM 26 (FIG. 2), and further the segment SIDATA 28f is disposed in the internal RAM 27 (FIG. 2). In FIG. 17, 0x means an address indicated by hexadecimal notation, the segment SCONST 28a is disposed in order from an address (0x000000), the segment DATA 28c is disposed in order from an address (0x100000), and the segment SIDATA 28f is disposed in order from an address (0xffe000).
Since memory capacity and disposition are different depending upon the type of a microcomputer, the programmer 51 disadvantageously fails to memorize all address information about that type, and can not grasp an actual image of memory disposition. More specifically, the programmer 51 can not grasp at which address in the memory space a ROM is disposed or at which address a RAM is disposed. Conventionally, the programmer 51, when making the LDF 53, makes it using a text editor, etc., with reference to a specification and manuals 52a, 52b prepared for each microcomputer.
The programmer 51 is needed to check whether or not contents of the description of the LDF 53 are correct, looking at the LDF 53 thus made, and further verify contents of the description in the LDF 53. The verification is to check whether or not the object files 58a to 58c can be linked, whether or not instruction codes and variable data can be disposed in a designated memory area, and whether or not they are actually disposed. When as the result of the verification they can not be disposed in a predetermined manner, the linker 54 outputs error, and hence the programmer 51 must correct the contents. The programmer 51 repeats works of such verification and correction until the error is removed to make the LDF 53.
FIG. 16 is a flow chart schematically illustrating a conventional method of making the LDF. The method will be described with reference to FIGS. 15 and 16. In the first place, in step S1, the programmer 51 checks memory disposition information of a microcomputer with reference to a manual 52a of the microcomputer. The memory information includes necessary information such as addresses and sizes of a ROM/RAM contained in the microcomputer. Instep S2, the programmer 51 makes the LDF 53 based upon the memory disposition information using the text making tool 56, display 59, and input means 62. The text making tool 56 has functions of inputting and editing characters, and makes the LDF data illustrated in FIG. 12 and stores it in the LDF 53. In step S3, the programmer 51 checks whether or not there is description error in contents of the made LDF 53 referring to the manual 52a of the microcomputer.
In step S4, the programmer 51, if there is any error in the description of the LDF data, corrects it using the text making tool 56, and rewrites the LDF 53.
In step S5, the programmer 51 subjects the object files 58a to 58c to the link processing with the aid of the linker 54 based upon the made LDF 53.
The linker 54 executes verification processing together with the link processing. For example, when predetermined segments are not settled in the range of the memory disposition information described in the device file 61, the linker 54 outputs error information. The programmer 51 can verify the LDF data and check presence of any error using the linker 54.
In step S6, the programmer 51 checks presence of any link error. When there is any error due to the LDF data, the programmer 51 advances to presence, and the programmer 51 again repeats steps S4 to S5 until the cycle error is removed to complete the LDF 53. When there is no error or when there is error not related to the LDF, there is no problem in the contents of the LDF 53. The programmer 51 thus completes the LDF making processing.
FIG. 17 exemplarily illustrates a result of the link processing where the object files 58a to 58c are subjected to the link processing with the aid of the linker 54 based upon the LDF 53. As illustrated in the same figure, the sections in each segment 28a to 28f are combined, and sections xe2x80x9c. dataxe2x80x9d, . . . belonging to the segment DATA 28c are disposed within a predetermined range from an address (0x100000), and xe2x80x9c. tidata. bytexe2x80x9d, . . . belonging to the segment SIDATA 28f are disposed within a predetermined range.
Since for the aforesaid text pointer symbol tp_TEXT and global pointer symbol gp_DATA their actual addresses are determined when they are converted to the execute form file 60, in the LDF 53 illustrated in FIG. 15 only kinds of symbols used and attributes f the same are described on the lines LD26 to LD28, and actual addresses are not designated.
It is ordinarily unknown how much the SCONST segment 28a occupies a memory area. For this, the programmer 51 disposes it behind the SCONST segment 28a and defines it without designating start address of the TEXT segment 28b, whereby the LDF 53 is easily made. Since the linker 54 can make a program in the TEXT segment 28b with a relative address which takes as a reference an address designated by the text pointer symbol tp_TEXT, it is unnecessary to rewrite an address to be branched in the TEXT segment 28b even if the size of the SCONST segment 28a is varied. A programmer can effectively develop a program by using such pointers, as described above.
Such a conventional method of making the LDF however suffers from a difficulty that when the LDF is written manually, it takes much labor until it is finished because mistaken description is inevitable. More specifically, a programmer makes the LDF manually in the state where it is difficult to know an image of actual disposition of instruction codes although he can check memory disposition information, etc., of a microcomputer from its manual.
The programmer is accordingly obliged to promote works in a trial and error so that he might often take mistakes: he forgets necessary information or erroneously describes any information. Thus, he takes much time for works such as check and correction of contents of the works.
In order to reduce mistaken description an expert is required for making the LDF, and hence LDF making work is limited. Further, the made LDF must be verified with the linker, so that further labor is needed to complete the work.
Since memory capacity and disposition are different for each type of microcomputers, even an expert can not memorize such information. The programmer 51 must search any page of a thick manual on which necessary information is described, and detect memory disposition information. This work requires much time, and further lowers development efficiency of a program.
The present invention has been made to solve the aforesaid problems of the prior art, and has an object to provide a method of making a link directive file capable of simply grasping memory disposition and size information upon developing a program for an information processing apparatus such as a microcomputer and upon using link processing and making a link directive file, and further provide a tool for making the aforesaid link directive file.
To achieve the aforesaid object, a method of making a link directive file, the file being used for link processing where a plurality of objects are linked to an execute form file and disposing instruction codes and variable data in a memory space, according to a first aspect of the present invention, is featured by comprising the step of: visually displaying the aforesaid link directive file as a memory image.
In the foregoing, a mode is desirable wherein a method of making a link directive file is featured by that a plurality of kinds of memories are disposed in the aforesaid memory space, and for the memories kinds of the memories and start addresses of the memories are displayed in the order of addresses.
Further, a mode is desirable wherein a method of making a link directive file is featured by that the aforesaid execute form file includes a plurality of different attribute segments, and names of said segments and start addresses of the aforesaid segments are displayed in the order of the addresses in the aforesaid memory space.
Furthermore, a mode is desirable wherein a method of making a link directive file is featured by that each the aforesaid segment includes a plurality of different attribute sections, and names of the aforesaid sections and start addresses of the aforesaid sections are displayed in the order of the addresses in the aforesaid memory space.
According to a second aspect of the present invention, a method of automatically making a link directive file used for link processing where a plurality of object files are linked into an execute form file to dispose instruction codes and variable data in a memory space and instruct the aforesaid instruction codes and the aforesaid variable data, is featured by that the method comprises the step of comparing the size of the memory disposed in the aforesaid memory space and the size of the aforesaid instruction codes or the aforesaid variable data to be added or altered, and judging whether or not the aforesaid instruction codes or the aforesaid variable data can be disposed.
According to a third aspect of the present invention, a method of making a link directive file which is used for link processing where a plurality of object files are linked into an execute form file to dispose instruction codes and variable data in a memory space, is featured by that the method comprises the step of: reading memory disposition information from a device file containing at least address size information concerning each individual device; reading the aforesaid link directive file for instructing a disposition position of each constituent component of the aforesaid object file; visually displaying the aforesaid memory disposition information and the aforesaid link directive data on a display as a memory image; and altering contents of a part needed to be altered on the aforesaid memory image referring to the aforesaid memory image to alter the aforesaid memory image.
In the foregoing, a mode is desirable wherein a method of making a link directive file according to the third aspect is featured by that a memory image is displayed on the basis of default said directive information inherent to a device.
Further, a mode is desirable wherein a method of making a link directive file is featured by that memory information from the aforesaid device file and directive data from the aforesaid link directive file, and link directive data concerning an execute form from an execute form file are read to display on the aforesaid display a memory image after the link processing.
Furthermore, a mode is desirable wherein information of a part on the aforesaid memory image is selected to display information of a lower hierarchy of said information.
According to a fourth aspect of the present invention, a tool for making a link directive file, the file being used for link processing where a plurality of object files are linked into an execute form file to dispose instruction codes and variable data in a memory space, is featured by comprising : memory disposition information storage means for storing therein memory disposition information containing at least address size information concerning each individual device; link directive file data holding means for holding link directive file data for indicating a position where a constituent element of the aforesaid object file is disposed in the execute form file; memory image display means for displaying the memory image on the basis of the aforesaid memory information held in the aforesaid memory disposition information storage means and the aforesaid link directive data held in the aforesaid link directive file data holding means; and data edit means for altering contents of information of a part needed to be altered on the aforesaid memory image with reference to the aforesaid memory image to update the aforesaid memory image.
In the foregoing, a mode is desirable wherein a tool for making a link directive file is featured by that there is provided link directive file read means for reading the link directive file.
Further, a mode is desirable wherein a tool for making a link directive file according to the tenth or eleventh aspect is featured by that there is provided execute form analysis means for reading the execute form file after subjected to the link processing, analyzing constituent elements of the execute form file, and storing the link directive information in the aforesaid link directive file data holding means.
Furthermore, a mode is desirable wherein a tool for making a link directive file is featured by that the aforesaid data edit means has a function in which partial information on said memory image is selected to display lower rank hierarchy information of the aforesaid information.
Still furthermore, a mode is desirable wherein a tool for making a link directive file is featured by that there is provided default link directive file data holding means.
In accordance with a method of making an LDF of the present invention and a tool for making a tool of the present invention, as described above, amemory image is visually displayed on a display so that a memory image of a microcomputer is simply successfully grasped.
Moreover, the LDF is automatically made by altering contents of information of a part on a memory image needed to be altered, and updating the memory image while looking at the memory image.
The LDF is automatically made without relying on those skilled in the art.